The session initiation protocol or “SIP” is an application-layer control protocol for creating, modifying, and terminating sessions between communicating parties. The sessions include Internet multimedia conferences, Internet telephone calls, and multimedia distribution. Members in a session can communicate via unicast, multicast, or a mesh of unicast communications.
The SIP protocol is described in Handley et. al., SIP: Session Initiation Protocol, Internet Engineering Task Force (IETF) Request for Comments (RFC) 2543, March, 1999, the disclosure of which is incorporated herein by reference in its entirety. A related protocol used to describe sessions between communicating parties is the session description protocol. The session description protocol is described in Handley and Jacobsen, SDP: Session Description Protocol, IETF RFC 2327, April 1998, the disclosure of which is incorporated herein by reference in its entirety.
The SIP protocol defines several types of entities involved in establishing sessions between calling and called parties. These entities include: proxy servers, redirect servers, user agent clients, and user agent servers. A proxy server is an intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation to other servers. A proxy interprets, and, if necessary, rewrites a request message before forwarding the request. An example of a request in the SIP protocol is an INVITE message used to invite the recipient to participate in a session.
A user agent server is an application that contacts a user when a SIP request is received and that returns a response on behalf of the user. A user agent client is an application that initiates a SIP request. In a SIP network, user agent client and server software may execute on an end user device, such as a SIP telephone, to initiate and accept calls on behalf of the user.
A redirect server accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to a client. Unlike a proxy server, a redirect server does not initiate its own SIP requests. Unlike a user agent server, a redirect server does not accept calls.
According to the SIP protocol, objects are identified by SIP URLs. A SIP URL may be of the form user@host. The user part may be a user name or a telephone number. A called party may move between a number of different systems or locations over time. These locations may be dynamically registered with a SIP server. A location server may also use one or more other protocols, such as finger, rwhois, LDAP, multicast protocols, or other operating-system-dependent mechanisms to locate an end system where the called party might be reachable.
FIG. 1 is a message flow diagram recreated from the above-referenced SIP protocol specification that illustrates the function of the SIP proxy server in establishing a typical SIP call. In FIG. 1, a user with a SIP URL of cz@cs.tu-berlin.de located at a first computer 100 in the domain cs.berlin.de is attempting to establish a call with another userwith a SIP URL of henning@cs.col. In order to initiate the call, in step 1, the SIP user agent software resident on computer 100 sends an INVITE message to a SIP proxy server 102. The INVITE message includes the SIP URL of the called party, i.e., henning@cs.col. Since SIP proxy server 102 may not know the actual location of the user henning@cs.col, in step 2, SIP proxy server 102 queries a location server 104 to determine where to send the INVITE message. In step 3, location server 104 responds with the current location of the user “henning”. In the illustrated example, the location is specified as hgs@lab.
In step 4, SIP proxy server 102 forwards the INVITE message to computer 106 at which the user “henning” is located. SIP user agent software resident on computer 106 responds to the INVITE message with a 200 OKAY message indicating acceptance to the invitation to the session. In step 7, SIP proxy server 102 forwards the 200 OKAY message to computer 100. In step 8, computer 100 forwards an acknowledgement message to SIP proxy server 102. In step 9, SIP proxy server 102 forwards the acknowledgement message to computer 106. Once the acknowledgement is received by computer 106, a multi-media session is established between the two users.
One potential problem that is not addressed in the SIP protocol specification is how to reliably and efficiently provide location information to SIP servers, such as SIP proxy servers and SIP redirect servers. Conventional SIP servers utilize a centralized database, as illustrated in FIG. 1, to obtain SIP location information. This solution is undesirable because using a centralized server to provide the location information causes a performance bottleneck at the location server. That is, as the number of subscribers and location queries increase, the location server can become overwhelmed with location requests. As a result, location requests may be delayed or even dropped by the location server.
Another problem that is not addressed by the SIP protocol specification is how to provide reliability and scalability in SIP protocol servers, such as proxy servers and redirect servers. As the number of SIP users increases, the demands on SIP protocol servers will also increase. If a SIP protocol server fails, users may be left without SIP signaling service. The SIP protocol specification does not address methods of increasing scalability or reliability of SIP protocol servers. The SIP protocol specification merely discusses the functional requirements of these servers, in general.
Thus, there exists a long felt need for a scalable, reliable SIP signaling router that avoids at least some of the difficulties not addressed by the SIP protocol specification or by conventional SIP signaling routers.